Email.cgi version 5.0

"Email.cgi, since 1994. One of the older, if not the oldest, continually supported CGI scripts for the Macintosh. Still free."

Introduction
Requirements
Installation
Required input tags and the simplest form
Many inputs
User required inputs
Unwrapping input
Special variables
Template files and more special variables
Environment variables
Error messages
Revision history

Introduction

The purpose of email.cgi is to extract the contents of an HTML form and send those contents to one or more email addresses.

Email.cgi supports carbon copied and well as blind carbon copied messages. It allows for required fields giving Webmasters to ability to mandate data-entry for specific inputs before processing will be completed. Email.cgi has two types of output: output to an email address and output in the form of HTML documents. Both types are highly customizable. No configuration is necessary to the program itself; all customizations are done through the creation of HTML forms. Email.cgi captures and optionally returns the bits of information sent by Web browsers (environment variables) describing their operating environment. The source code for email.cgi is freely available so you can make changes as you see fit.

Using email.cgi writers of HTML documents can create things such as but not limited to: surveys, order forms, requests for more information, front-ends to mailing list commands, comment forms, purchase requests, votes and polls, etc. Combined with your desktop email program's filtering functions you will be able to use email.cgi to automatically update databases, process mailing list requests, or return automated email replies to specific questions.

Email.cgi should be completely backwards compatible with older versions of the program. The forms you created using the older versions of email.cgi should work just fine with this newer version. The only difference you will see is the format of the program's output files.

Below is an example of what email.cgi can do. It's email output will be sent to me, and once I recieve it I will simply reply allowing you to see it too. Items marked with an asterisk (*) are required fields, but see what happens when you don't supply them. Powerusers can view the source of this form to get a quickstart with email.cgi.

Simple email.cgi demonstration form

What is your name?*

What is your email address?*

Have you used email.cgi before today?

Choose a font color

If you know how or want to learn how to write HTML forms, and you can meet the hardware and software requirements listed below, then you can use email.cgi.

Enjoy email.cgi. Have fun with it.

Requirements

Email.cgi is an AppleScript CGI application for Macintosh computers. It requires the following hardware and software:

A Macintosh computer connected to the Internet.
AppleScript, preferably the version coming with MacOS 8.0 or greater. (I'm not sure, but you might need version 8.6)
A Web (HTTP) server supporting common gateway interface (CGI) scripts. Just about all Web servers support CGI scripts. MacHTTP, WebSTAR, NetPresenz, Quid Pro Quo, as well as Personal Web Sharing all work just fine.
Access to a local, simple mail transfer protocol (SMTP) server. Believe it or not, you've probably got one of these.
MondoMail, an AppleScriptable SMTP mailing agent, also available locally.
Parse CGI OSAX, an AppleScript extension simplifying the process of extracting form elements into programing variables, also available locally.
And of course, the email.cgi program itself.

Installation

Installation is not difficult. Here's how:

Get your Web server up and running. Describing how to do this is beyond the scope of these instructions. Sorry. Really.
Download MondoMail, save it anywhere on your hard disk, and note it's location.
Download Parse CGI OSAX, drop it on a your closed System folder, and it should be automatically saved in your Scripting Additions Folder. (If the computer did not tell you where it was putting the OSAX, then it probably did not put it in the right place and you will have to move it to the Scripting Additions Folder manually.)
Download email.cgi and save it anyplace where it will be available to your Web server. Often times there will be a folder named "scripts" or "cgi-bin" for the purposes of things like email.cgi.
Double-click on email.cgi. It should ask you for the location of MondoMail. Locate MondoMail and then manually quit email.cgi.
Finally, you might have to reboot your server.

Congratulations! You are now ready to write your first email.cgi form.

Required input tags and the simplest form

To use email.cgi you write HTML forms making sure your their action attributes point to email.cgi and their method attribute is POST. Additionally, the program requires, at the very least, three specifically named input tags in order to function correctly: to_address, from_address and mailer. These input tags are defined below:

to_address
This is an email.cgi required field. All email.cgi forms must contain an input tag with this name, and the value of the input must be a valid email address (or addresses). The type of this input will most likely be hidden. For example, if I wanted the contents of an email.cgi form to be sent to me, then I would create a form with the following input tag:

<input type="hidden" name="to_address" value="eric_morgan@ncsu.edu">

The value of this input tag is not limited to a single email address; you can have email.cgi send its output to multiple email addresses by stringing together multiple values delimited by commas. For example, I could send the output of an email.cgi form to two of my email accounts by using the following input tag:

<input type="hidden" name="to_address" value="eric_morgan@ncsu.edu,ericmorgan@aol.com">

You are not limited to the input type of hidden for this required variable. Input types like radio buttons, pop-up menus, and simple text inputs will work correctly as long as the input is valid. On the other hand, email.cgi will not function correctly, yet, if you use multiple-selection scrolling lists or check boxes as your input types. (Can you say "creeping featuritis"?).

from_address
This is an email.cgi required field. The value for this input tag is a valid email address. Email.cgi uses the contents of this tag as the email address of the person who is sending email. For example:

<input type="text" name="from_address">

If users of your forms supply an invalid email address, then you are up the creek; there is little you can do to prevent people from entering invalid values in this field. Sorry. Really.

mailer
This is an email.cgi required field. All email.cgi forms must contain an input tag with this name, and the value of the input must be the Internet name or IP address of a valid, accessible Simple Mail Transfer Protocol (SMTP) server. You can most likely discover the Internet name or IP address of your local SMTP server by examining the preferences of your desktop email program because your email program requires an SMTP server in order to function correctly. This input tag will almost always be hidden and an example includes the following:

<input type="hidden" name="mailer" value="mail-relay.ncsu.edu">

The form below illustrates and demonstrates just about the simplest possbile email.cgi form. Once you submit it you should get the default email.cgi output that includes all the variables sent to the form as well as the "free environment variables" sent by your browser.
<form action="./email.cgi" method="POST"> to_address: <input type="text" name="to_address" value="eric_morgan@ncsu.edu"><br> from_address: <input type="text" name="from_address"><br> mailer: <input type="text" name="mailer" value="mail-relay.ncsu.edu"><br> <input type="submit" value="submit"> </form>
Try it.

to_address:
from_address:
mailer:

Of course you will want to create forms containing a variety of inputs such a check boxes, radio buttons, text inputs, etc. The form below includes a few of these input types and again returns the default output.

<form action="./email.cgi" method="POST">
<!-- include to_address and mailer, but hide them since the end-users don't need to know --><input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu">
<!-- let's do a pizza delivery, first the size using radio buttons -->size:
<input type="radio" name="size" value="small">small
<input type="radio" name="size" value="medium">medium
<input type="radio" name="size" value="large" checked>large
<input type="radio" name="size" value="extra large">extra large
<br>
<!-- now some toppings with check boxes -->toppings:
<input type="checkbox" name="topping" value="mushrooms" checked>mushrooms
<input type="checkbox" name="topping" value="onions">onions
<input type="checkbox" name="topping" value="peppers">peppers
<input type="checkbox" name="topping" value="peperoni" checked>peperoni
<br>
<!-- don't forget their from_address, a required field -->email address: <input type="text" name="from_address"><br>
<!-- get their telephone number using simple text input -->telephone number: <input type="text" name="telephone" value="1 800 555 1212"><br>
<input type="submit" value="submit">
</form>

Try it.

User required inputs

Often times you will want to require end-users to supply various inputs. This function is supported by email.cgi when you prepend the name of a form's input tag with user_required_. For example, if you want to require the end-user to supply their first name, then one of your input tags might look like this:

<input type="text" name="user_required_firstname">

When submitted, the following form, in its default state, will return the default error message. When the form is submitted and every field includes a value, the default email.cgi output will be returned.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> first name: <input type="text" name="user_required_firstname"><br>last name: <input type="text" name="user_required_lastname"><br> email address: <input type="text" name="from_address"><br> <input type="submit" value="submit"> </form>
Try it.

first name:
last name:
email address:

Unwrapping input

Email.cgi allows you to have the return characters removed from the contents of your form. This is called unwrapping and proves useful when using the <textarea></textarea> input tags. To unwrap the contents of your inputs include unwrap_ anywhere in its name.

The following form includes two <textarea></textarea> input tags. When submitted the default email.cgi output will be returned. The contents of the first <textarea></textarea> input tag will not be unwrapped, the second one will be unwrapped.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> <p>email address: <input type="text" name="from_address"></p> <P>a story:<br><textarea rows=7 cols=50 name="a story">There lives a young girl in Lancaster town, Whose hair is shiny pale green. She lives at the bottom of Morgan's farm pond, So she's really too hard to be seen. </textarea></P> <P>another story:<br><textarea rows=7 cols=50 name="unwrap_another story">Once upon a time there were three bears: Daddy Bear, Mommy Bear, and Baby Bear. They lived in a nice house in the forest, and one summer day they went for a walk. Along came a girl named Goldy Locks. She discovered the bear's empty house and decided to make a mess. The bears came home, and they were angry. Goldy Locks rans away. The end. </textarea></P> <input type="submit" value="submit"> </form>
Try it.

email address:

a story:
There lives a young girl in Lancaster town, Whose hair is shiny pale green. She lives at the bottom of Morgan's farm pond, So she's really too hard to be seen.

another story:
Once upon a time there were three bears: Daddy Bear, Mommy Bear, and Baby Bear. They lived in a nice house in the forest, and one summer day they went for a walk. Along came a girl named Goldy Locks. She discovered the bear's empty house and decided to make a mess. The bears came home, and they were angry. Goldy Locks rans away. The end.

Special variables

There are a number of special variable names you can give input tags in order to enhance processing. These variable names include: debugMode, subject, cc, bcc, and redirect. Each of these variables and their functions are described below, but do not use these variable names unless you want to have email.cgi perform these functions:

debugMode
An input tag with this name and given any value will cause email.cgi to simply return a list of all its given inputs and then exit. A tag with this name is usually hidden and used only for validation purposes. For example:

<input type="hidden" name="debugMode" value="1">

Remember, the value of this tag can be any value other than empty ("") in order to function correctly.

subject
The value of an input field with this name becomes the subject of the email message being sent by email.cgi. Often times you will want to make this a hidden field so users cannot edit it and you can filter your incoming email.cgi output accordingly. For example:

<input type="hidden" name="subject" value="problem report">

If you do not supply an input tag named subject in your forms, then email.cgi defaults the value of subject to "Email.cgi output".

cc
An input tag given this name "carbon copies" email.cgi output to sets of one or more email addresses. Just like the required input tag to_address, the value of input tags named cc must contain one or more valid email addresses. If multiple carbon copied email addresses are desired, then you must concatonate them together with commas. Examples include:

<input type="hidden" name="cc" value="eric_morgan@ncsu.edu">

or

<input type="hidden" name="cc" value="ericmorgan@aol.com,emorgan@sunsite.berkeley.edu">

Only one input tag named cc is allowed per email.cgi form.

bcc
Input tags with this name work just like the input tags for tags named cc except values are used for "blind carbon copied" email messages. An example includes:

<input type="hidden" name="bcc" value="eric_morgan@ncsu.edu">

Only one input tag named bcc is allowed per email.cgi form.

redirect
The provision of an input tag named redirect is one way email.cgi can return the end-user an HTML page other than the default email.cgi output. The default email.cgi output is functional, but not very aesthetically pleasing. By assigning a full URL to the value of an input tag named redirect, email.cgi will process the form's content and tell the end-user's browser to go to the a pre-defined HTML page written as a results page:

<input type="hidden" name="redirect" value="http://152.1.24.177/email/redirect-page.html">

Only one input tag named redirect is allowed per email.cgi form.

The forms below illustrate and demonstrate the use of these special variables. This first form demonstrates the use of debugMode.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> <input type="hidden" name="from_address" value="mr_debug@errorsrus.com"> debug mode: <input type="radio" name="debugMode" value="1" checked>on <input type="radio" name="debugMode" value="">off<br> <input type="submit" value="submit"> </form>
Try it.

debug mode: on off

This second form illustrates and demonstrates the use of subject, cc, and bcc.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> <input type="hidden" name="cc" value="ericmorgan@aol.com"><input type="hidden" name="bcc" value="emorgan@sunsite.berkeley.edu"> What is your email address? <input type="text" name="from_address"><br>What fruit do you want to know more about? <select name="subject"><option value="apples">apples <option value="oranges">oranges <option value="cherries">cherries <option value="pears">pears </select><br> <input type="submit" value="submit"> </form>
Give it a whirl.

What is your email address?
What fruit do you want to know more about?

The last form of this section demonstrates the use of the redirect special variable.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> <input type="hidden" name="redirect" value="http://152.1.24.177/email/redirect-page.html"> email address: <input type="text" name="from_address"><br> <input type="submit" value="submit"> </form>
Visit Screaming Man...

email address:

Template files and more special variables

Through the use of a feature called "template files" and a few more special variables you can customize email.cgi's output. (Remember, email.cgi's default output is intended to be functional, not beutiful.)

There are three types of template files corresponding to the three types of email.cgi output: email, HTML, and error. Associated with these three templates are three more special vaiables: mail_template, html_template, and error_template, used respectively.

The process behind the use of template files is similar for each type:

Create a valid email.cgi form.
Include an input tag with the name of a template file special variable (ie. mail_template, html_template, and/or error_template).
Assign a value to the input tag corresponding to the name of a file in the same folder as email.cgi.
Create a template file with the name of the corresponding input tag and save it in the same folder as email.cgi.
Edit your template file and include the names of desired email.cgi form input tags making sure the names are surrounded by square brackets ([]). These names surrounded by square brackets are called "tokens" and examples include [to_address], [subject], or [your name]. Be forewarned! The tokens, san brackets, must match exactly the names of the input tags. Case matters.

If done correctly, email.cgi will process the content of your forms, read your template file(s), find/replace the names of your input tags in the files with the values supplied in the form, and finally, return the dynamically created output. ("Kewl," you say, "just what I've always wanted!" Eric says, "Yes, I know. I've heard it many, many times. Your wish is my command.")

Each special variable associated with template files is described below:

mail_template
Use this special variable associated with an existing template file to format the email sent by email.cgi. It allows you to create email.cgi email messages sent to you in such a way that it will be easy for you to process them once recieved. For example, if you administrate a mailing list, then you might be able to create an email.cgi form, have it's output formatted into a mailing list command, and sent to the mailing list server for processing on the end-user's behalf. If you want to import the contents of forms into a database, then the mail_template file may be tab-delimeted for easy processing. Remember, the contents of your email output is not necessarily intended to be read by humans; you can format the output so it can be read by computers. This feature also allows you to selectively add or delete any of the "free environment variables" returned by the default email.cgi message output. An example input tag includes:

<input type="hidden" name="mail_template" value="problem-report-mail">

html_template
This special variable is associated with the HTML template page returned to the end-user after they submit a form. Through the use of this special variable you can echo the end-user's input in a manner congruant with the style of your site. Here is a sample input tag:

<input type="hidden" name="html_template" value="problem-report-html">

error_template
Use this special variable and its accociated template file to format any error messages email.cgi may generate. Like the html_template special variable, this special variable's purpose is to allow you to create output that looks like the balance of your HTML pages. An example includes:

<input type="hidden" name="html_template" value="problem-report-error">

Remember the following two distinctions concerning the use of this special variable. First, if any email.cgi error occurs and the error_template does not point to a valid error template file, then email.cgi really generated two errors but will report the error_template error before it will report anything else. To minimize this problem, make sure all other errors are resolved before you use this special variable.

Second, a specific token is used as a placeholder for email.cgi error messages, [email.cgi error message]. Insert this specific token in your error_template file so the error message makes more sense to your end-users.

Finally, here's a hint. Create your form first and get it working before you start adding template files, then add the template files one at a time making sure the error_template file is implemented last. The following form includes these all three of the special variables associated with template files.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"> <input type="hidden" name="support person" value="Eric"> <input type="hidden" name="mail_template" value="problem-report-mail"><input type="hidden" name="html_template" value="problem-report-html"><input type="hidden" name="error_template" value="problem-report-error"> What is your name? <input type="text" name="user_required_name"><br>What is your email address? <input type="text" name="from_address"><br>Select the type of problem: <select name="subject"><option value="making money">making money <option value="saving money">saving money <option value="spending money">spending money <option value="none of these">none of these </select><br>What's the problem?<br><textarea rows="7" cols="30" name="user_required_unwrap_problem"></textarea><br> <input type="submit" value="submit"> </form>
Here are the corresponding template files. First the very simple mail_template (problem-report-mail):
name: [user_required_name]
email address: [from_address]
subject: [subject]
problem: [user_required_unwrap_problem]
Next, here is the html_template file (problem-report-html):
<html><head><title>[subject]</title></head><body>
<h2>Thank you</h2>
<P> Dear [user_required_name], thank you for completing
the problem report. We will look into your problem,
[subject], as you described it below right away: </P>
<blockquote>[user_required_unwrap_problem]
</blockquote>
<P> If you have any other problems, the please direct
them to <a href="mailto:[to_address]">[support
person]</a>. </P>
<P>Have a nice day.
</P>
<P>Signed, The Management
</P>
</body></html>
Finally, the error_template (problem-report-error):
<html><head><title>Oops!</title></head><body>
<H1>Oops!</H1>
<P>Oops! Some sort of error occured:
</p>
<blockquote>[email.cgi error message]
</blockquote>
<p>Maybe you didn't complete all the necessary fields
in the form? Try again, and if the problem persists,
then please report it to The Management. </P>
</body></html>
Now go for it; try the form.

What is your name?
What is your email address?
Select the type of problem:
What's the problem?

Environment variables

As you may or may not know, Web browsers send tiny bits of information about themselves to remote Web servers and therefore CGI programs. These tiny bits of information are usually called environment variables. Email.cgi gives these environment variables to you for "free" and incorporates them into its default output or by design through the use of template files and tokens. There are 9 such "free environment variables" supported by email.cgi, and they are all described below:

client_ip_address
This environment variable will echo the IP address of the machine submitting the email.cgi form.

client_name_address
This returns the fully-qualified Internet name of the remote machine used to submit the email.cgi form. If no fully-qualified Internet name is available, it will default to the remote machine's IP address.

client_browser
This environment variable returns the name of the end-user's Web browser, in all its glory. This variable will give you a clue to the type of computer your end-users are using.

user_name
If email.cgi is accessed through some sort of authentication process, then the username used to gain access to the script will be echoed here.

user_info
I do not know that this environment variable is impelemented by very many browsers, but if it is, then it most likely contains the email address of the remote end-user as it is configured in their browser.

server_info
This will return the IP address or Internet name of your HTTP server. Its not much use unless you are using email.cgi on multiple HTTP servers.

server_port
Each HTTP server operates under at TCP/IP "port" where a port is much like the extension of a telephone number. The vast majority of the time, this variable will return the number 80, the default port for HTTP communications. Again, this is not much use unless you administrate multiple servers.

execution_path
This echos the path to your email.cgi script(s) relative to the root of your HTTP server's document folder. There is no reason why you can't have multiple copies of email.cgi on your server(s). With the inclusion of this environment variable in the output of email.cgi, you can determine which copy of email.cgi was run.

the_referrer
This free environment variable is the most fun. It returns a complete URL of the page where the the email.cgi form was submitted. Like execution_path, you can use this variable to see where requests are coming from and whether or not your script is being "hijacked" by others on remote servers.
Remember, to incorporate the environment variables in the output(s) of email.cgi you must treat each of them as if they were tokens described in the template files section above. In other words, you must insert the names of the variables in your template files exactly as they are shown above and they must be delimited by square brackets ([]).

The form below and its associated html_template file echos all the environment variables.
<form action="./email.cgi" method="POST"> <input type="hidden" name="to_address" value="eric_morgan@ncsu.edu"><input type="hidden" name="mailer" value="mail-relay.ncsu.edu"><input type="hidden" name="html_template" value="environment-html"> What is your name? <input type="text" name="user_required_name"><br>What is your email address? <input type="text" name="from_address"><br> <input type="submit" value="submit"> </form>
Here is the template file:
<html><head><title>Environment variables </title></head> <body> <h2>Environment variables</h2> <P><b>[user_required_name]</b>, the following "free environment variables" were returned by email.cgi: </P> <ol><li>client_ip_address - [client_ip_address] <li>client_name_address - [client_name_address] <li>client_browser - [client_browser] <li>user_name - [user_name] <li>user_info - [user_info] <li>server_info - [server_info] <li>server_port - [server_port] <li>execution_path - [execution_path] <li>the_referrer - [the_referrer] </ol> <P>Thank you for using email.cgi. </P> </body></html>
Okay, here goes...

What is your name?
What is your email address?

Error messages

There are fourteen errors email.cgi traps. Each is associated with an error message. Some occur because there are missing values for required or end-user required variables. Other errors occur because of invald values for supplied template files. The balance of the error messages you will probably not encounter. If you do, then there is most likely something wrong with your installation or the logic of email.cgi itself. Each of the error messages are described below:

Email.cgi error #1: no to_address variable defined
This error is reported when the HTML author has not specified who (or what) is suppose to get the email output.

Email.cgi error #2: no from_address variable defined
This happens when no email address of the sender is specified. Hint, hint. If you, as the HTML author don't really care about who is submitting the form, then make from_address a hidden variable filled with a bogus value.

Email.cgi error #3: no mailer variable defined
When this error is reported a name or IP address of your SMTP host (mailer) is not supplied. Power users may want to hard code the value of their SMTP host into the AppleScript of email.cgi. This is left as an exercise up to the reader. Sorry.

Email.cgi error #4: can't fill list of fields
You should never get this error because I got it enough when I was writing the program. It probably occcured because of a logic error in the program. Note the complete error message and then email it to me.

Email.cgi error #5: can't extract environment variables
Ibid.

End-user error: user_required field missing
This will most likely be the most frequently occuring error. It is returned when a user required (user_required_) field is not supplied by the end-user. ("The crystal ball sees 'creeping featuritis' in my future because of this particular message.")

Email.cgi error #6: can't capture extra fields
See Error #4.

Email.cgi error #7: can't format debug output
Ibid.

Email.cgi error #8: can't return formatted debug output
Ibid.

Email.cgi error #9: can't build default email output
Ibid.

Email.cgi error #10: can't send email output
If you get this message, then MondoMail could not execute. This is a bit misleading because even if MondoMail could execute, your mail may not be sent. MondoMail queues messages for delivery and does not report about successfully sent messages. MondoMail only reports errors in it's error log saved as text in same folder as MondoMail itself. If mail does not seem to be getting through, then checking MondoMail's error log is your first line of defense.

Email.cgi error #11: can't build default html output
See Error #4.

Email.cgi error #12: template file not found
One of the three types of template files specfied in the email.cgi form did not exist in the same folder as email.cgi. Check the value of the template file variable and make sure it matches the name of a file in the same folder as email.cgi

Email.cgi error #13 (MacOS error)
If for some reason email.cgi cannot open your template file, and the error was not that the file didn't exist, then this error is generated. I doubt you will get this error message. If you do get this error, then see Error #4.

Revision history

5.0 (July 12, 1999)
After searching long and hard for an adequate find/replace routine, I was able to implement the template files feature so many people requested. I am indepted to the venerable cgiemail progrgam of the Unix flavor that I have always admired. It gave me all the ideas. Added user-required fields as well as unwrapped fields. This version also gives the user access to the environment variables. Subject is no longer a required variable. The documentation was completely re-written. Much of the program itself was re-written. I have to hand it to Apple. My older coding contained an internal variable called message. Apparently this has some sort of special meaning with the newer implementation of AppleScript and the "handle CGI request" AppleEvent because all my message variable names were changed to |message|. Weird, but functional. I see creeping featuritis in my future with the implementation of more customizable error messages and a pseudo-environment varible called date.

4.0.2 (Novemer 11, 1998)
This revision is not released; it only exists on my local Web server for people to test. Too many people were hijacking my script without downloading it to their server. Consequently, I have removed the redirection feaeture from the demo version and I have put a red reminder message in the other sample output. Also, since our FTP server no longer exists, I have moved the archive to an HTTP server.

4.0.1 (Febrary 6, 1998)
AOL browsers returned errors saying they could not retrieve the results of email.cgi. Similarly, NetPresenze tried to download the entire copy of email.cgi based on executions. I resolved these issues by including an HTTP header in the default output of the script. It should have been there in the first place! Thank you Ian Cabell and Northland Productions.

4.0 (March 18, 1997)
Got rid of the TCP/IP OSAX in favor of MondoMail. Consequently, email.cgi is completely free again. Added the ability to include redirection so alternative reply pages can be incorporated. Because of MondoMail, multiple TO addresses as well as CC and BCC addresses are now possible. Because of MondoMail, the from_name and to_name required variables are no longer supported. "Yea, Acme Technologies!"

3.0.9 (June 19, 1996)
The from_name and to_name variables were passed incorrectly to the send_as_text routine. Thank you, Fred Hicks.

3.0.8 (June 14, 1996)
Updated the script to work correctly with the the newer version of the TCP/IP Scripting Addtions, and thus, email.cgi now works with Open Transport. Additionally, while the script works as an .acgi application, everybody's milage varies. Consequently, I am not advocating the use of this script as an .acgi application.

3.0.7 (March 6, 1996)
Removed a / mark in the feed back so there could be a valid html tag. (Thank you, Timothy Toole.)

3.0.6 (January 11, 1996)
Still putzing with the quote marks and user names. For right or for wrong, I removed them from the MAIL FROM: and RCPT TO: command. I may have to edit the To: and From: commands to include parentheses and not quote marks. ("RTFM, Eric!")

3.0.5 (Never released)

3.0.3 (December 22, 1995)
A number of people said they were getting weird communication errors (parameter not reconized). After surrounding my "Mail-To" and "Reply-To" commands with quotes, these problem dissappeared. Why have these problems not surrfaced before?

3.0.2 (December 8, 1995)
For the longest time I knew that email.cgi did not disconnect (close) the TCP connection correctly. Then when both Adrian Sullivan and then Erik De Vocht pointed out that I could use MacTCP Watcher to monitor my TCP connections I discovered how to fix the problem. (Its rather embarassing, but all I did was add the word "stream" to the close command.) In any event, email.cgi now closes connections after each transmission (I hope). Furthermore, I configured email.cgi to work as a .acgi program and automatically quit after 30 seconds. If you want to tweek with this then you will have to do it yourself. A hearty "Thank you!" goes to Adrian Sullivan and Erik De Vocht.

3.0.1 (August 11, 1995)
In version 3.0 I reintroduced an SMTP protocol faupaux from version 2.0 by sending the from_name and to_name variables as a part of the MAIL FROM: and RCPT TO: commands. This has been corrected, and they have been removed. "Thank you Steve Mathesius for pointing out the errors of my ways."

3.0 (August 11, 1995)
Introduced the ability to deliever the output of (hopefully) any FORM to an email address, as long as the FORM included the required variables.

2.0.1 (July 20, 1995)
Upon futher examination, I realized the MAIL FROM: SMTP command, as well as the RCPT TO: command, I was implementing was incorrect; I was including human names in these command when that is not what you are suppose to do. Consequently, after removing the human names from these commands, email.cgi works with more mailers. "Thank you, Bill Bowman."

2.0 (July 10, 1995)
After being given an SMTP library from Atul Butte, I changed the script to include the HELO command for initialting SMTP communications. This, as well as a few slight modifications to the library should make email.cgi work happily with MailShare. Whew! I also upgraded the script with the use of the Parse CGI OSAX thus eliminating the tedious method of extracting the POST arguments from the FORM. Very nice! Lastly, I added much more error trapping and consequently, it is no less prone to returning garbage.

1.0.2 (January 6, 1995)
Prompted by Todd Main, and using code from Tom Coradeschi, I changed email.cgi to inclued the ability to send the end-user's name as well as their adress in the email header. "Thanks guys!"

1.0.1 (November 9, 1994)
IMHO, the TCP Scripting Additions version 1.1.2 were not backwards compatible with version 1.1. Specifically, the calls to the ISO translation tables were changed. Consequently, the older compiled version of email.cgi did not work. By installing the newer version of the Scripting Additions (1.1.2) and recompiling email.cgi, the problems with email.cgi and Scripting Additions have disappeared. Thus, email.cgi version 1.0.1 is not backwards compatible either. Arggg...

1.0 (November 2, 1994)
Original release intended to 1) demonstrate the possibilities of AppleScript CGI scripting, and 2) offer the possibilities of mailto: functionality for MacWeb browsers.

Author(s): Morgan, Eric Lease (eric_morgan@ncsu.edu)
Date created: Wednesday, November 2, 1994
Date updated: Monday, July 12, 1999
Subject(s): AppleScript; CGI (common gateway interface); SMTP (Simple Mail Transfer Protocol)
URL: http://www.lib.ncsu.edu/staff/morgan/email-cgi.html

Simple email.cgi demonstration form
What is your name?*
What is your email address?*
Have you used email.cgi before today?
Choose a font color